Fixes #10854. A bare reduce_by: [<time_dimension>] (or group_by, or the grain: directive's exclude/keep_only) silently does nothing when the query projects that time dimension with a granularity.

Problem

Projected time dimensions are TimeDimensionSymbols whose full_name carries a granularity suffix (created_at_day, created_at_month, ...), and the suffix survives the whole reference chain. A bare grain entry compiles to a plain DimensionSymbol (orders.created_at), so the full_name-based matching in the planner never matches it — the entry is silently ignored, the time dimension stays in (or vanishes from) the partition, and window aggregates collapse to one-row partitions. Sums per day instead of running totals, ranks of 1 everywhere — no error, no warning.

This bites at two sites: the window path's PARTITION BY computation, and the JOIN-model path's leaf-grain shaping (partition_filter), which carried a FIXME warning the two copies would drift if only one was updated.

Fix

The granularity-aware matching now lives on MultiStageGrain itself (partition_dimensions()), and both sites delegate to it — removing the duplicated body and discharging that FIXME. The matching rule:

• an entry with an explicit granularity (created_at.month) matches strictly on full_name — group_by: [created_at.month] keeps only the month projection, not sibling granularities;
• a bare entry matches the dimension at any granularity, by unwrapping both sides to their base symbol.

The asymmetry is deliberate: an earlier draft that unwrapped unconditionally broke queries projecting multiple granularities of the same time dimension, which the multi-granularity test below now pins.

Because the legacy reduce_by/group_by and the new grain: directive compile through the same grain construction, the fix covers both spellings.

Testing

Four integration tests (executed against postgres via testcontainers, result-level snapshots):

• reduce_by_time_dim — bare reduce_by on the window path; fails without the fix (per-month splits instead of per-status totals)
• reduce_by_time_dim_join_model — same bug via a type: max measure, which is not window-eligible and exercises the partition_filter site; fails without the fix
• grain_exclude_time_dim_join_model — bare time-dim exclude spelled via the grain: directive with a non-empty include (forces the JOIN-model path); fails without the fix
• group_by_time_dim_multiple_granularities — guard test pinning the strict-match behaviour for explicit granularities; passes with and without the fix by design

Two adjacent issues are deliberately out of scope and can be follow-ups: granularity-qualified entries in filter directives (filter: exclude: [created_at.month]) match nothing for date-range filters, and grain.include of a bare time dimension can add a duplicate grouping next to an already-projected granularity.